Keynote Talk : Formal Veri cation : The Art of Being

s from the 1989 HOL Users Group Meeting Phillip J. Windley (Editor) Division of Computer Science Department of Electrical Engineering and Computer Science University of California, Davis December 14-15, 1989 Editor's Note The 1989 HOL User's Group Meeting was held December 14-15, 1989 at Trinity Hall College, Cambridge University. This document gives abstracts, prepared individually by the speakers, of the technical presentations from the conference. For more information on a given talk, please contact the authors directly via electronic mail; their addresses are provided. 1 2 Keynote Talk: Formal Veri cation: The Art of Being Economical with the Truth Keith Hanna [email protected] University of Kent, UK Design veri cation can be seen as a game played between society, wishing to protect itself from disaster, and designers, wishing to promote their products. Society's interests are entrusted to an authority whose task is to select a veri cation method and oversee its application. A veri cation method has two components: a formal logic and an interpretation. The purpose of the former component is (to borrow a phrase) to be \economical with the truth;" its axioms and rules of inference should be few in number and self-evidently sound. Higher-order logic can adequately meet this requirement. The purpose of the latter component, the interpretation, is to relate the formal logic to the physical world. It is vitally important that this relationship be examined with full rigor; the meaning of each primitive symbol must be precisely de ned, the truth of each axiom and the intent of each de nition must be checked. This activity lies at the intersection of engineering and logic and thus responsibility (between designer and logician) for undertaking it can be blurred. This in turn can lead to a situation where the use of formal methods actually decreases design integrity; the logician veri es the design against simplistic (i.e., false) assumptions and the engineer, knowing that the design will be \formally veri ed," lets drop his guard. A criterion sometimes advanced for formal veri cation is \Would I y it?." This is a rather weak test to apply since experience tells us that most designs do, in fact, work satisfactorily most of the time. A stronger criterion for formal veri cation would be game-based, perhaps along the following lines: \Would I entrust myself to an apparatus designed and veri ed (albeit strictly in accordance with the rules of the veri cation method), not by a benign engineer, but rather by an omniscient demon setting out, with malicious intent, to exploit every weakness in the formal logic, fragility in its computational implementation and imprecision in its interpretation?." The second part of the talk described VERITAS+, a design logic having dependent types and subtypes [1]. Such types are useful for describing the bounded entities (e.g., n-bit numerals) typically occurring in digital system speci cations. For example, the function val that maps a numeral to a number may be given the dependent type: val: [b:natp] * [l:nat] -> V(b,l) -> N (b exp l) (Read as: val takes a positive natural number b and a natural number l and then takes a length-l base-b numeral, and yields a natural number in the subrange less than b to the power 3 of l.) The penalty incurred in the use of dependent types is the loss of decidable type-checking; in practice, a tactic-based approach allows a reasonable degree of automation to be realized. The main advantage of dependent types is the increased clarity of speci cations. References: 1. \Speci cation and Veri cation using Dependent Types," Technical Report, University of Kent, 1989. 1 SOFTWARE AND PROTOCOL VERIFICATION 4 1 Software and Protocol Veri cation Session Chair: Roger Hale, Cambridge University December 14, Afternoon Speakers: John Cullyer Railway Signalling Rachel Cardell-Oliver Specifying and Verifying a Class of Protocols Albert Cammilleri Mechanizing CSP Trace Theory in HOL Joakim von Wright Formalizing Program Re nements 1 SOFTWARE AND PROTOCOL VERIFICATION 5 Railway Signalling John Cullyer [email protected] Warwick Univeristy, UK Abstract not available 1 SOFTWARE AND PROTOCOL VERIFICATION 6 Ideas for Specifying a Class of Protocols and Verifying Implementations using Higher Order Logic Rachel Cardell-Oliver rco%[email protected] Cambridge Univeristy and Defense Science and Technology Organization, Australia Computer network protocols are members of the class of real time concurrent programs. The class of protocols which, say, transfers data from one place to another in a computer network share not only the same function, but also the same behavior in the sense of the basic mechanisms which all these protocols use. The most obvious similarity between protocols of the same class is their physical structure. Each protocol is e ected by a sender and receiver (programs on separate computers) which communicate, only, via a bi-directional channel. Protocol structure is captured in HOL using techniques developed for hardware speci cation. Each physical entity (sender, receiver and channel) is modeled by a higher order predicate and communication between the entities is modeled by shared parameters to these predicates. Less obvious to model is the mechanism for reliable communication over an unreliable channel: positive acknowledgment. Each data message which is transmitted must be acknowledged by a returned message. Transmission and reception predicates in the sender and receiver achieve this by continuously transmitting data or acknowledgments (respectively) and using local state variables to chart progress. Properties which vary between protocols of the same class are captured by parameters of the speci cation. For example, window sizes and channel delays are modeled by parameters of type sequence and time respectively. The choice of which data message to send next is modeled by a parameter of type time ! sequence which, at any time, chooses the next message to transmit. The correctness of a protocol depends on complex real time interactions between the sender and receiver programs and the channel. The channel's response is non-deterministic. For example, messages may be delivered or lost and if delivered may be delayed for a variable, but bounded, time. Real time intervals are speci ed using a constant added or subtracted from the current time. For example a timeout occurs at time t if the value of the sender's state at time t is the same as its state at time t TIMEOUT . Protocol liveness is determined by an interval of maximum persistence, maxP , in the sender. That is, the protocol will be aborted if the sender's state at time t is the same as its state at time t maxP . Veri cation that the protocol behavior speci cation discussed above satis es the functional speci cation for a class is still in progress but near completion. Earlier speci cations are being 1 SOFTWARE AND PROTOCOL VERIFICATION 7 restructured and the proofs updated. The next task is to specify and verify real time protocol implementations. The following is a possible route for performing this task. 1. De ne mappings between the names of program variables in an implementation and the variables of the HOL speci cation. 2. De ne the relationship between the real time scales of the program and the abstract time scales of the HOL speci cation. Techniques for doing this can be found in the work of Tom Melham, Je Joyce, John Herbert. 3. Show, possibly using Floyd-Hoare proof rules, that the updated values of program variables correspond to the updated variables of the HOL speci cation. A HOL description of a Floyd-Hoare proof system similar to the one de ned by Mike Gordon could be used for this task. 4. Interpret real time events such as packet arrival and timeout. Should these be modeled using polling, a wait statement which jumps to rst condition to be satis ed, a ag held high until the event is recognized etc.? Finally, having shown that a particular implementation is a member of the class of data transfer protocols, I would like to prove that it is a non-trivial member of that class by proving properties about the protocol's performance. One option for doing this is to assign probabilities to the non-deterministic choices of the channel and from this deduce real time performance properties of the protocol. 1 SOFTWARE AND PROTOCOL VERIFICATION 8 Mechanizing CSP Trace Theory in HOL Albert Cammilleri ac@[email protected] Hewlett Packard Laboratories, UK In this talk I describe a mechanization of the formal language CSP in higher order logic. CSP is one of several process algebras developed for reasoning about concurrency and communication, and mathematical proof plays a major part in reasoning using the language. The CSP semantics modeled in HOL is that of traces. This is one of the simplest semantic models developed for CSP over the years, but is nonetheless useful and provides insight into the nature of the problems involved in mechanizing the process algebra, and the practicality of the nal results. One thing which immediately becomes evident from the mechanization is the amount of general mathematics required for reasoning in the semantics of CSP (e.g. set theory, xed points). The talk describes the mechanization of some fundamental CSP notions such as events, alphabets and traces using the necessary mathematical foundations, and how a data type is de ned to represent CSP processes. It is shown how the trace semantics of the CSP operators are de ned conservatively on this data type, and how high level process algebra laws are derived from the de nitions of the operators. Finally it is shown how the adopted semantics can be separated from the syntax of the language by rst de ning a syntactic type of CSP processes using Melham's type de nition package, and then formalizing a denotational semantics for the language using the trace semantics. 1 SOFTWARE AND PROTOCOL VERIFICATION 9 Formalizing Program Re nements Joakim von Wright jwright@ nabo.abo. Abo Academi, Finland The re nement calculus is a theory of correctness preserving program transformations, based on based on Dijkstra's weakest precondition. It has proved useful for di erent kinds of program development, including data re nement and development of parallel programs. We write S <= S 0 (saying that S is re ned by S 0) if wp(S;Q) => wp(S 0; Q) holds for all predicates Q. Thus the relation <= preserves total correctness. Program development in the re nement calculus starts from a speci cation S0, and through a series S0 <= S1 <= ::: <= Sn of transformations, ends with a program Sn. Our goal using HOL is threefold. First, we want to formalize re nement concepts in HOL (i.e., de ne a speci cation language with weakest precondition semantics). Second, we want to check the proofs of re nement laws and transformation rules. Third, we want to do program re nements within the HOL theory of re nement, program development resulting in a theorem ` S0 <= Sn within the re nement theory. Working within the same theory where the transformation rules were proved correct guarantees that the basis for the work is solid. We de ne predicates semantically, as the type state ! bool, where state is the type var ! val. The variables could be strings and the values natural numbers. Operators on predicates are de ned by lifting, e.g. (p and q) is de ned as (s : state) : s p ^ s q Expressions have type state ! val. Substitutions on predicates are a bit tricky to de ne, since predicates are not syntactically de ned. Predicate transformers have type pred! pred. Among other things we prove that every monotonic predicate transformer has a least xpoint. Commands are a recursive type cmd. Our language is Dijkstra's guarded commands, extended with assertions, nondeterministic assignment and block with local variables. The semantics is given by a function wp : cmd ! pred ! pred, associating every command with its weakest precondition predicate transformer. For iteration we give a xpoint de nition, thus permitting nondeterminism to be unbounded. The re nement relation is de ned in a straightforward way. 1 SOFTWARE AND PROTOCOL VERIFICATION 10 As a test of our formalization, we have proved, among other things, Dijkstra's \healthiness conditions" (strictness, monotonicity and conjunctivity) of the wp function. Strictness and monotonicity were simple but conjunctivity was hard. In fact we could not prove conjunctivity of iteration in the case of unbounded nondeterminism (this seems to require the use of ordinal chains and trans nite induction). We have also attempted to prove re nement laws, which various case studies have shown to be useful. Many general laws were easy to prove. Rules concerning loops (iteration) were more di cult. Re nement of assignment statements were also sometimes di cult to prove. This is because the semantics of assignments involves substitutions. An important property of the re nement relation is subcomponent monotonicity: any subcomponent S of a program T can be replaced by another program fragment S 0, if S <= S 0 holds. This method can be automated by considering the program T to be an application ( X : T (X))S. We have written an ML function which takes two arguments: the theorem ` S <= S 0 and the term X : T (X) and which returns the theorem ` T (S) <= T (S 0) This shows that the principle of program derivation in small steps can be used. So far we have only worked with very small examples. Besides aiming at larger examples we are also trying to make the theory more general. This involves extending the language with e.g., recursion and multiple assignments. The block construct has proved to be a problem; it seems necessary to index the re nement relation with a list of global variables in order to make the theory strong enough to handle local variables. This will also be a focus of future work. 2 HARDWARE VERIFICATION SESSION 11 2 Hardware Veri cation Session Session Chair: John Herbert, Cambridge University December 15, Morning Speakers: Luc Claesen CHEOPS: Interfacing HOL to CATHEDRAL Shiu-Kai Chin Combining Hardware Synthesis and Silicon Compilation David Sheperd SAFEMOS Phillip J. Windley Hierarchical Veri cation of Microprocessors 2 HARDWARE VERIFICATION SESSION 12 CHEOPS: Interfacing HOL to CATHEDRAL Luc Claesen [email protected] IMEC, Belgium A basic research action cooperation among IMEC, the HOL-group at the University of Cambridge and Philips (Dr. A. Kalker) will concentrate around the formal proof of steps in the CATHEDRAL-synthesis systems. The CATHEDRAL synthesis systems are silicon compilers dedicated towards the automatic synthesis of digital signal processing systems. These systems are encountered in telecommunication, digital audio, radar etc.. Cathedral-1 is targeted towards bit-serial implementations of signal processing systems [1]. Cathedral-2 does the synthesis in multi-processor dedicated micro-programmed chip architectures [2]. The synthesis in Cathedral-2 starts from a high level algorithm speci cation in the applicative SILAGE language. In a rst step, a customized datapath allocation is done with a tool called Jack-the-Mapper. This tools builds up the datapaths according to the requirements from the algorithm. It allows to make tradeo s between area and speed. After the datapath allocation a scheduling of the operations on the datapath is done with the ATOMICS program. The number of busses can be reduced by bus merging at the cost of a few additional cycles. In Cathedral-2 a generic controller structure is used. After the scheduling the controllers are generated in the CGE program. At this point the interconnection of all physical building blocks is known and the layout phase can start. In Cathedral-2 a number of prede ned parameterized modules exist (ALU, ACU, MULT, ...) that can be adapted in a very exible way to the application at hand. In this project the goal is to use the HOL system to try to verify the results of the synthesis processes in CATHEDRAL. The development of complicated proofs and theories will be payed o by their more frequent use in the cross check of a synthesis process. Even in more established so called "correct-by-construction" processes such as standard-cell or gate array layout generation, cross checks are done via tools such as netlist comparison. Probably not all of the tasks in the CATHEDRAL silicon compilation environment will be as tractable to be used for correctness proof by HOL. Therefore individual aspects of the CATHEDRAL system will be attacked rst, starting with the parameterized module libraries. The future goal is to develop constructive methods, based on transformational design, that will result in proven synthesis steps in CATHEDRAL as well as in manual design steps. References: 1. \Custom design of a VLSI PCM-FDM transmultiplexer from system speci cations to circuit layout using a computer aided design system", R. Jain, F. Catthoor, J. Vanhoof, 2 HARDWARE VERIFICATION SESSION 13 B. Deloore, G. Goosens, N. Goncalves, L. Claesen, H. Van Ginderdeuren, J. Vandewalle, H. De Man, Joint special issue of the IEEE transactions on Circuits and Systems Vol. CAS-33, No.2, pp. 183-195, February 1986, and the IEEE Journal of Solid-State Circuits Volume SC-21, No.1, pp. 73-85, February 1986, on VLSI analog and digital signal processing. 2. \CATHEDRAL-II: A Silicon Compiler for Digital Signal Processing Multiprocessor VLSI Systems", H. De Man, J. Rabaey, P. Six, L. Claesen, IEEE Design and Test of Computers, Vol.3, Nr.6, December 1986, pp.13-26. 2 HARDWARE VERIFICATION SESSION14Combining Hardware Synthesis andSilicon CompilationShiu-Kai [email protected] UniversityOne of the main objectives of this e ort is to increase the level of machine-executableand machine-veri ed design knowledge. The rate of increase in the level of abstraction ofdesign procedures must track corresponding increases in circuit integration to keep the level ofhuman design e ort for large systems manageable. The availability of machine-executable andmachine veri ed design procedures enables designers to design at a higher level of abstractionwith con dence. Towards this end, several ongoing e orts have been undertaken and aresummarized below.1. Veri ed design functions for inner product hardware.Several higher order functions used to create inner product hardware have been describedand veri ed in HOL. The synthesis functions support general signed-binary representa-tions and are parametric in wordsize and interconnection schemes. Some of the resultsare reported in [1,2,3].2. Linkages to silicon compilers.One of our objectives is to use the above functions to create designs which are thenlayed out using a commercial cell library and silicon compiler. Currently, we are usingSilicon Compiler System's Generator Development Tools (GDT). GDT supports bothfull custom, semi-custom, and standard cell design. GDT uses parametric cell generatorsto instantiate speci c layouts and is capable of creating a speci c layout from a registertransfer level schematic consisting of standard and user de ned cells.We also intend to incorporate the synthesis functions described above into Mike Four-man's LAMBDA system [4]. Our hope is that schematics generated by LAMBDA usingveri ed design rules can be used as inputs for GDT.3. An experiment verifying an abstract machine for a declarative languageAs part of another project, we are developing a language which combines both functionaland logic programming paradigms within a reduction setting. This language is an extensionof J. Alan Robinson's LOGLISP language.The abstract machine underlying the language [5,6] is a combination of the Three InstructMachine (TIM) [7] and the Warren Abstract Machine (WAM) [8]. We have described the 2 HARDWARE VERIFICATION SESSION15semantics of the language in [6] using Plotkin style operational semantics [9]. Proofs relatingthe abstract machine to the language have been done using the CLIO theorem prover.Also, preliminary designs have been done to create hardware supporting the abstract ma-chine. The VLSI designs have been done using the GDT tool set.References1. Chin, S.-K. and Stabler, E.P., "Synthesis of Arithmetic Hardware Using Hardware Meta-Functions", to appear in IEEE Transactions on Computer-Aided-Design, 8/90.2. Chin, S.-K., "Veri ed Synthesis Functions for Negabinary Arithmetic Hardware", Ap-plied Formal Methods for Correct VLSI Design, Luc Claesen Editor, Elsevier.3. Chin, S.-K., \Combining Engineering Vigor with Mathematical Rigor," Hardware Spec-i cation, Veri cation and Synthesis: Mathematical Aspects, Editors: M. Leeser and G.Brown, Lecture Notes in Computer Science, Volume 408, Springer-Verlag, 1990.4. Fourman, M. P., Harris, R. L., \Lambda Logic and Mathematics Behind Design Au-tomation,"Abstract Hardware Limited, Uxbridge, UB8 3PH, U.K.5. Jamsek, D., Greene, K.J., Chin S.-K., Humenn, P.R., \WINTER: Wams IN Tim Expres-sion Reduction," Proceedings of the North American Logic Programming Conference,Cleveland, Ohio, October 16-19, 1989.6. Jamsek, D.A., Chin, S.-K. Structured Operational Semantics for a Combined Functionand Logic Programming Language, CASE Center Technical Report No. 8915, SyracuseUniversity, Syracuse, NY, January 23, 1990.7. Fairbairn, J., Wray, S., \TIM: a simple lazy abstract machine to execute supercombina-tors," Proceedings of the Functional Languages and Computer Architecture Conference,1987.8. Warren, D.H.D., \An abstract PROLOG instruction set," SRI International TechnicalNote 306, 1983.9. Plotkin, G.D., \A Structured Approach to Operational Semantics," Technical ReportDAIMI FN-19, Computer Science Department, Aarhus University, September 1981. 2 HARDWARE VERIFICATION SESSION16SAFEMOSDavid [email protected] Limited, UKApology I started with an apology that I had expected to have several weeks in which toprepare material to present at the meeting but that this time had suddenly disappeared whenI was given the task of sorting out the INMOS end of an ESPRIT project proposal. Hence mytalk would consist of a brief introduction to the SAFEMOS project followed by some materialI had prepared earlier but not used.Project ReportsSAFEMOS The SAFEMOS1 project is an UK DTI IED project whose partners areINMOS ltdSRI International Cambridge Research CenterOxford University Programming Research GroupCambridge University Computer LaboratoryThe aim of the project is to \demonstrate the possibility of totally veri ed systems".This will be achieved by designing a language (similar to occam), a program veri er for thatlanguage, a veri ed compiler and a veri ed processor. Using these an veri ed program can berun securely using a veri ed processor and compiler. The project had just o cially startedand would last 3 years. Veri cation work would be based around HOL.DECISIVE Also mentioned was the proposed ESPRIT DECISIVE2 project. Proposedpartners for this areSiemensSGS-Thomson Microelectronics1SAFEMOS is not and acronym.2DECISIVE is an acronym of DEsign of Correct Industrial Systems by Interactive VEri cation. 2 HARDWARE VERIFICATION SESSION17INMOS LtdAbstract Hardware LimitedHarlequin LtdLaboratory for the Foundations of Computer Science (Edinburgh University)CEABPart of this project would aim to take the results from projects like SAFEMOS and toproduce industrially usable tools for veri ed design. Areas of interest at INMOS includedveri ed synthesis of hardware and mixed hardware/software systems.Design Methodology The main part of the presentation used some foils I had preparedsome time earlier to describe how a consistent methodology could be used to design hardwarein both a top-down and bottom-up manner which could be incorporated with a CAD designdatabase.The problem was that when designing a module that includes submodules you have toeither already have designed the sub-modules, forcing design to be bottom up, or to usespeci cations of the submodules. If speci cations are used then when implementations areproduced a proof has to be performed to replace the speci cations by implementations. Also,the designer needs to know which sub-modules are implemented and which are still just im-plementations.The method suggested involved treating sub-modules as extra parameters to the module.Then the correctness statement of a module was of the form\For all sub-modules implementations(each sub-module implementation implies its speci cation)implies the module with those sub-modules implies its speci cation"For example for a 4 bit adder with 1-bit adder submodules this would be in HOL8ADDER IMP(8x?; y?; cin?; s!; cout! : coutADDER IMP (x?; y?; cin?; s!; cout!)) ADDER SPEC(x?; y?; cin?; s!; cout!)))8cin?; cout : sig; x?; y?; s! : bus4ADDER4 IMP ADDER IMP (x?; y?; cin?; z!; cout!)) ADDER4 SPEC(x?; y?; cin?; z!; cout!) 2 HARDWARE VERIFICATION SESSION18The proof of this is much easier than might appear as suitable applications of rewriting,STRIP_TAC and RES_TAC reduce to the \normal" proof.At some level the designer encounters true implemented modules. These have a correctnessterm of the form \implementation implies speci cation". Such implementations without sub-module parameters are termed \realizations" to indicate that they are for-real designs. Arealization can be used in a higher level modules and by instantiating them in the parameterlist of that module. Now using modus ponens with the speci cation term for the realization andthat of the enclosing module one of the relevant sub-module assumption in the implementationcan be removed. Once all sub-module parameters are replaced by realizations the module itselfbecomes a realization.The bene ts of this technique are\Realizations" are always genuine usable designs | a realization can only be constructedout of other realizations.Design can be top-down or bottom-up as sections can be left as speci cations.Annotations were shown on how this method could be added to the INMOS HDL toallow for inclusion in CAD tools. 2 HARDWARE VERIFICATION SESSION19Semi-Custom Veri cationPhillip J. [email protected] of California, DavisThe terms \custom" and \semi{custom" have come to have particular meanings in thechip fabrication business. A \semi{custom" VLSI chip is one fabricated from pre{designedgate arrays, making it both cheaper to fabricate and less e cient (in space and time) than afully custom design. We use these words in a analogous manner to describe the veri cationof a microprocessor that can be changed with little reveri cation cost, but with some lose ofexibility.Formal veri cation promises to provide increased con dence that computer systems meettheir speci cations; but to realize this bene t, the cost and complexity of formal veri cationmust be reduced. To date, veri cation has primarily been used in safety{critical and security{critical computer systems where the cost and complexity can be justi ed. Other systems,however, could bene t from the application of formal methods if simpler means of verifyinghardware and software can be found.Several microprocessors have been veri ed using formal methods. Each of these veri ca-tions has been \full{custom," that is, each microprocessor design and subsequent veri cationwas done to some custom speci cation. Because of the complexity of verifying real computersystems, the only successful veri cation e orts have been on relatively simple microprocessorarchitectures (fewer than 32 words of micro{instruction store, small instruction set, limitedfeatures for supporting operating systems, etc.). The largest of these microprocessors, theVIPER microprocessor, was abandoned due to the large amount of human e ort seeminglyrequired to complete the proof.This talk discusses the formal veri cation of a microprocessor, but more importantly, wepresent a theory of interpreter hierarchies that provides a means of signi cantly reducingthe complexity of microprocessor veri cation. This theory is embodied in a set of tools andtechniques for the HOL theorem prover. We present the theory and a discussion of how thistheory leads to the \semi{custom" veri cation of microprocessors making formal methodsmore accessible to the design engineer. For a more detailed treatment of this research see[1,2].Reference:1. Windley, Phillip J.,\A Hierarchical Methodology for Verifying Microprogrammed Mi-croprocessors," University of California, Davis Division of Computer Science ResearchReport No. CSE-89-27, November, 1989. 2 HARDWARE VERIFICATION SESSION202. Windley, Phillip J, \The Semi-Custom Veri cation of Microprocessors," University ofCalifornia, Davis Division of Computer Science Research Report No. CSE-90-1, January,1990. 3 FOUNDATIONS SESSION.213 Foundations Session.Session Chair: Tom Melham, Cambridge UniversityDecember 15, AfternoonSpeakers:Ton KalkerWell-ordering and Cardinals in HOLElsa GunterAbstract Theories for HOLSten Agerholm Automating a Model CheckerHenrik SkjoedtStig Pedersen Modeling of Diagnostic Reasoning 3 FOUNDATIONS SESSION.22Well-ordering and Cardinals in HOLTon [email protected] Research Laboratories, The NeatherlandsThe notion of a well-ordering as de ned in ordinary set theory is recalled: A linear orderingon a set S is called a well-ordering if every non-empty subset E of S has a smallest element.A famous theorem of Zermelo (1904) asserts the fact that the axiom of choice is equivalentto every set having at least one well-ordering. As in the HOL logic the axiom of choice isautomatic by the presence of the Hilbert choice operator, the above mentioned set-theoreticalfact can be translated to the HOL logic. We showed how set theory can be \simulated" inHOL by representing sets as predicates on types, and then gave an outline of the prove. Thecomplete prove can be found in the library well ordering of HOL88.Having well orderings available gives us the tool for formulating the trans nite-inductionprinciple, which is a straightforward generalization of the general induction tactic for naturals.We showed the formulation of this induction tactic and mentioned the associated tactics andrules, which can also be found in the library well ordering.As an application of the library well ordering and the library quotient we did a shortoutline of a theory about cardinals. We showed how with the help of a quotient constructcardinals can be de ned: they are just classes of equipotent sets, where as before sets aremodeled as predicates on types. Set inclusion is extended to a partial order on cardinals.To prove the fact this this ordering is even linear, we need trans nite induction. Trans niteinduction is used to show that:if set A can not be surjected onto set B,thenthere exists an embedding of A into B.We closed the talk with saying that the full details can be found in the library of HOL88, andthat the work done showed that HOL can be used for non trivial math.A paper on well-orderings, cardinals, etc. in HOL will appear shortly. 3 FOUNDATIONS SESSION.23Abstract Theories for HOLElsa [email protected] of Pennsylvania, USAIn this talk an extension to the HOL theory mechanism is proposed, namely that of abstracttheories. An abstract theory extends the current notion of theory in HOL by allowing the userto abstract out of a theory type variables, term variables and theorem assumptions. Within atheory so bound, the bound type variables have the status (for almost all purposes) of 0-arytype constructors, the bound term variables have the status (again, for almost all purposes) ofmonomorphic constants, and the bound theorem assumptions have the status of axioms. Fromoutside the abstract theory these are bound type variables, bound term variables and boundtheorem assumptions, all awaiting instantiation. The goal of adding such a construct to HOLwould be to facilitate the natural development and use within HOL of abstract mathematicaltheories with repeated application.The attributes of an abstract theory are to be:Type Binder (list of type variables)Term Binder (list of term variables (with their types))Theory Assumptions (list of pairs of strings and terms of type bool)Parent Theories (list of theories and abstract theories)Type ConstructorsConstantsAxiomsDe nitionsTheoremsThe functions for interaction with abstract theories are to be as follows:For declaring a new abstract theory:new_abstract_theory: string -> type list -> term list ->(string # term) list -> void 3 FOUNDATIONS SESSION.24where{ string is the name of the abstract theory.{ type list is a list of type variables to be treated (almost) as type constants fromwithin the abstract theory.{ term list is a list of term variables to be treated (almost) as monomorphic con-stants from within the abstract theory. The types of the term variables can onlyinvolve those variables found in the type list.{ (string # term) list is a list of labeled propositions which are treated as axiomsfrom within the theory. The propositions may involve those type variables andthose free term variables appearing respectively in either the type list or the termlist.For extending or loading an abstract theory:extend_abstract_theory: string -> voidload_abstract_theory: string -> voidThese commands allow for the addition of de nitions, type de nitions, and theorems topreviously created abstract theories.For closing an abstract theory:close_abstract_theory: void -> voidThis command returns HOL to previous concrete theory, and removes all ML identi erbindings made while the abstract theory was open.For instantiating a theorem:extract_theorem: string -> string -> thm.where{ The rst string is name of abstract theory.{ The second string is name of theorem in abstract theory.{ The thm returned is the result of discharging all the abstract theory assumptionsand generalizing all the the variables in the the term binder for the theorem named. 3 FOUNDATIONS SESSION.25For instantiating all of the abstract theories:apply_abstract_theory: string -> string -> type list -> term list ->thm list -> voidThis command incorporates into the current theory the results of instantiating all of thetheorems in the abstract theory with the values given in type list and term list, providedthat{ The rst string is the name of the abstract theory.{ The second string is a modi er to the names of the theorems from the abstracttheory.{ The type list provides values to instantiate the type variables in the type binderof the abstract theory.{ The term list provides values of the appropriate instantiated type to instantiatethe term variables in the term binder.{ The thm list provides theorems whose statements are the instantiated versions ofthe abstract theory assumptions.The following functions are used from within an abstract theory:The functionthy_asm: string -> thm.returns as a theorem one of the theory assumptions, provided that string is a label forthe theory assumption.For introducing new type operator:abs_new_type_definition: (string # term) -> thmwhere{ string is the name of the new type operator to be introduced.{ term is a predicate (containing no free variables) on an existing type which de nesa subset which, if non-empty, is to be in one-one correspondence with the typebeing de ned,This function introduces a new type operator with arity the same as the arity of thetype on which P is a predicate (for this purpose the types and terms in the binder ofthe theory are to be considered as free), ana which asserts an axiom stating 3 FOUNDATIONS SESSION.26|?rep.(!y z. (rep y = rep z) = (y = z)) /\(!x. (P x \/ (x = @y. P y)) = (?z. x = rep z))which is returned as a theorem.In addition, we would have the usual functions for internal interaction with concretetheories as currently existent, except that new type definition is prohibited, andnew de nition is required to not de ne a constant whose name is that of a term in thetheory binder. Within new definition, the terms of the theory binder are disallowed.In conclusion, the proposed notion of abstract theories provides a modest, consistent ex-tension to HOL, which we believe will provide a convenient environment for developing andapplying theories with assumption. In conjunction with the existing theory capacity of HOL,they should play the same role for theorem proving in-the-large as structures and functors(i.e. \modules") due in Standard ML. Moreover, they should remove all excuses for non-foundational uses of new-axiom. 3 FOUNDATIONS SESSION.27Automating a Model Checker forRecursive Modal Assertions in HOLSten AgerholmHenrik [email protected] University, DenmarkTransition systems are widely used in computer science, communication engineering andcircuit designing, among others, for modeling the behavior of both hardware and softwaresystems. For example, computer scientists use transition systems in studying nite stateconcurrent programs; the operational semantics of such can be given by nite labeled transitionsystems.Properties of states in nite labeled transition systems can be expressed using recursivemodal assertions. The assertion language we have implemented in the HOL system includesrecursive assertions de ned as maximum and minimum xed points. This language is powerfuland can be used to express properties such as `always', `eventually' and `deadlock', amongothers. In order to have the recursive assertions in HOL we proved a special version of Tarski'stheorem which provides a way of de ning and reasoning about maximum and minimum xedpoints.In general it can be quite hard work to prove by hand whether or not a state satis es anassertion, and it is therefore desirable to have a way of checking whether assertions are trueor false on states mechanically. We have implemented an algorithm which proves theorems inHOL, automatically, stating whether a state satis es an assertion or not.The model checking system consists of various tools which reduce the workload of the userto a minimum, for example the system does all the theorem proving needed. In addition, it ismade exible with respect to e ciency optimizations. 3 FOUNDATIONS SESSION.28Modeling of Causal andDiagnostic ReasoningStig Andur [email protected] University Center, DenmarkClinical reasoning is rendered di cult by the logical complexity of causal explanations of vari-ous diseases. A logical analysis of causal structures involved in clinical reasoning is presented.Disease causes are chosen as non-redundant parts of causal complexes. A causal complex is adescription of a situation which by necessity leads to the disease. Usually causal complexes areidenti ed by listing relatively few nonredundant components of it. It is argued that counter-factual conditionals (i.e., conditionals with false antecedents) play a decisive role during theconstruction and analysis of causal complexes and that we would gain a better understandingof causal reasoning by developing formal analyses of counterfactuals involved in such reason-ing. One such formal analysis is sketched. We believe that HOL will be a suitable tool forimplementing and further analyzing this logical system.